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FOREWORD 


This  task  was  conducted  in  response  to  a  reimbursable  work  request  from  the  Navy 
Science  Assistance  Program  office  under  work  unit  N60921-WR-W00155  (Evaluation  and 
Documentation  of  Ship-initiated  Microcomputer  Applications).  The  objective  of  the  work 
unit  was  to  document  and  evaluate  the  installation  and  use  of  a  microcomputer  system 
onboard  USS  COONTZ  (DDG  40)  and  USS  ARTHUR  W.  RADFORD  (DD  968).  This 
document  describes  the  effects  of  the  ship-initiated  microcomputer  applications  and  lists 
lessons  learned.  NPRDC  TN  82-28  provides  a  detailed  description  of  the  applications. 

Appreciation  is  expressed  to  the  men  of  COONTZ  and  ARTHUR  W.  RADFORD, 
whose  cooperation  and  assistance  aided  in  the  preparation  of  this  document.  Also, 
appreciation  is  expressed  to  Commander  Naval  Surface  Force,  U.S.  Atlantic  Fleet  for 
support  and  encouragement  in  the  use  of  nontactical  automated  data  processing 
equipment  aboard  ship. 


JAMES  F.  KELLY,  JR. 
Commanding  Officer 


JAMES  W.  TWEEDDALE 
Technical  Director 


Problem  and  Background 

The  shipboard  administrative  function  involves  manual  procedures  that,  in  the 
shipboard  environment,  waste  resources,  increase  likelihood  of  error,  and  reduce  the 
operational  efficiency  of  the  ship. 

Commander  Naval  Surface  Force,  U.S.  Atlantic  Fleet  authorized  USS  COONTZ  (DDG 
40)  and  USS  ARTHUR  W.  RADFORD  (DD  968)  to  lease  a  microcomputer  system 
containing  a  data  management  pnd  word  processing  capability.  The  data  management 
system  (DMS)  provided  for  the  creation,  maintenance,  and  reporting  of  data  from  user- 
defined  data  files.  The  word  processing  system  (WPS)  provided  for  the  creation  and 
production  of  letter-quality  documents. 

Objective 

The  objective  of  the  work  was  to  determine  the  effect  of  ship-initiated  micro¬ 
computer  applications  upon  general  shipboard  administration. 

Approach 

The  microcomputer  system  documentation  and  DMS/WPS  applications  were  reviewed. 
Interviews  were  conducted  with  shipboard  personnel  who  used  the  system.  Interview 
questions  concerned  application  design  and  development,  system  reliability  and  maintain¬ 
ability,  system  operations  and  utility,  system  personnel  and  logistic  support,  system 
benefits,  and  system  costs. 

Ship  readiness  data  to  evaluate  the  possible  effect  of  the  microcomputer  system  upon 
overall  ship  combat  readiness  were  not  available  because  of  security  classification. 
However,  applications  intended  to  support  day-to-day  ship  operations  were  analyzed. 

Results 


1.  COONTZ  and  RADFORD,  collectively,  developed  and  used  more  than  80  DMS 
and  200  WPS  applications  using  the  installed  microcomputer  systems.  The  overall  effect 
of  these  applications  upon  ship-internal  administration  and  ship  operations  was  positive. 
Each  application  met  a  specific  shipboard  management  requirement  and  saved  adminis¬ 
trative  time  and  labor  over  existing  manual  methods.  In  particular,  the  typing  backlog  in 
COONTZ  was  eliminated  by  distributing  the  WPS  capability  to  any  trained  user. 

2.  Microcomputer  user  and  supervisor  attitudes  toward  the  use  and  utility  of  the 
DMS/WPS  applications  were  favorable.  Supervisors  and  managers  indicated  that  the 
applications  enhanced  administrative  controls,  corporate  memory,  computer  literacy,  and 
job  satisfaction. 

3.  The  minicomputer  system  was  easy  to  install,  operate,  and  maintain  in  the  ship 
environment.  It  was  responsive  to  six  users  and  provided  average  automatic  data 
processing  equipment  (ADPE)  security.  Ten  megabytes  of  hard  disk  mass  storage  were  not 
sufficient  for  the  DMS/WPS  applications  in  COONTZ. 

4.  Fifteen  to  43  percent  of  the  ship's  company  personnel  support  was  required  to 
operate  the  ADPE,  develop/manage  DMS/WPS  applications,  and  train  system  users. 


5.  Minicomputer  system  hardware,  which  used  off-the-shelf  commercial  ADPC.  was 
100  percent  reliable  in  the  ship  and  sea  environment.  No  maintenance,  other  than 
minimal  preventive  maintenance,  was  required  for  the  ADPE  in  either  ship. 

Conclusions 

The  use  of  a  microcomputer  system  with  a  DMS/WPS  capability  for  automating  ship- 
internal  administrative  functions  generally  increased  clerical  productivity  and  operating 
efficiency  in  COONTZ  and  RADFORD.  The  introduction  of  a  like  capability  in  other  ships 
would  probably  produce  similar  results. 

Recom  mendations 


1.  Encourage  and  fund  micro-  or  minicomputer  ship-initiated  endeavors. 

2.  bicorporate  user-designed  and  command-managed  DMS  software  packages  into 
the  software  configuration  for  future  shipboard  nontactical  A  OP  implementation  pro¬ 
grams. 

3.  Design  shipboard  WPSs  to  support  multiple  WPS  terminals  for  use  by  personnel 
required  to  draft  or  produce  both  internal  and  external  distributed  documents. 
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INTRODUCTION 


Problem  and  Background 

The  shipboard  administration  function  involves  manual  procedures  that,  in  the 
shipboard  environment,  waste  resources,  increase  likelihood  of  error,  and  reduce  the 
operational  efficiency  of  the  ship. 

In  early  1980,  Commander  Naval  Surface  Force,  U.S.  Atlantic  Fleet,  authorized  USS 
COONTZ  (DDG  40)  and  USS  ARTHUR  W.  RA  WORD  (DD  968)  to  lease  a  microcomputer- 
based  data  management  system  (DMS).  The  microcomputer  system  on  both  ships  was  used 
over  a  12-month  period,  which  included  a  6-month  deployment  for  both  ships.  Since 
computers  have  the  potential  for  manipulating  nontactical  data  and  processing  text 
aboard  Navy  ships,  it  is  important  to  determine  how  these  applications  affected  shipboard 
administration  and  operations  and  to  identify  problems  and  "lessons  learned"  for  future 
ship  computer  installations. 

Objective 

The  objective  of  this  work  was  to  determine  the  effect  of  ship-initiated  micro¬ 
computer  applications  upon  general  shipboard  administration.  An  earlier  report  provided 
a  detailed  description  of  these  applications.1 


APPROACH 


Microcomputer  System  Description 

Hardware  and  System  Support  Software 

The  microcomputer  system  in  both  COONTZ  and  RADFORD  consisted  of  the 
following  hardware:2 

•  Alpha  Micro  AM-1031  microprocessor  system,  consisting  of  a  Western 
Digital  16-bit  central  processing  unit  (CPU)  with  256KB  MOS  memory,  12  input/output 
ports,  and  a  Control  Data  Corporation  CDC-9427H  disk  drive  unit  with  5KB  fixed  and 
5KB  removable  mass  storage  magnetic  hard  disks. 

e  Digital  Equipment  Corporation  DECwriter  III  LA-120  printer-terminal  with 
compressed  printing  for  up  to  220  column  outputs. 

e  Qume  daisy-wheel  letter  quality  terminal-printer. 

e  SOROC  IQ-120  video  display  terminals  (6) 


‘Dollard,  3.  A.,  &  Bockman,  R.  Ship-initiated  microcomputer  applications:  Detailed 
description  (NPRDC  Tech.  Note  82-28).  San  Diego:  Navy  Personnel  Research  and 
Development  Center,  September  1982. 

2 The  naming  of  commercial  products  does  not  imply  Navy  endorsement  of  those 
products. 


The  microprocessor  system,  DECwriter  LA-120  terminal-printer,  and  SOROC  video 
display  terminal  were  located  in  the  lower  combat  information  center  (CIC)  in  COONTZ 
and  in  the  Data  Bank  Technical  Library  in  RADFORD.  The  other  SOROC  video 
display  terminals  were  located  in  the  weapon's  department,  personnel,  ship's  administra¬ 
tive,  engineering  department,  and  supply  offices  aboard  both  ships.  In  COONTZ,  an 
additional  location  in  the  upper  CIC  was  wired  to  accommodate  a  cathode-ray  tube 
(CRT)  terminal  during  at-sea  periods.  The  Qume  letter-quality  terminal  printers  were 
located  in  each  ship's  administrative  office.  All  cabling  between  the  CPU  and  the 
peripheral  devices  used  military  standard  three-pair  shielded  cable,  which  was  laid  into 
each  ship's  existing  cable  ways  by  ship's  company  personnel.  The  entire  microcomputer 
system  was  powered  by  60Hz  electric  power.  Power  fluctuations  were  controlled  by  a 
constant  voltage  transformer  (CVT)  power  supply  and  line  filter.  Each  individual  unit  of 
the  microcomputer  system  could  be  carried  by  one  or  two  ship's  personnel  to  any  location 
on  the  ship  or  into  another  ship  without  difficulty. 

The  microprocessor  system  support  software  contained  a  multi-user,  multitasking, 
and  multiprogramming  operating  system.  This  software  provided  both  COONTZ  and  RAD¬ 
FORD  with  a  distributed,  interactive,  and  time-sharing  computer  system  for  up  to  six 
users  simultaneously.  This  was  accomplished  through  a  dedicated  system  monitor  that 
assigned  partitions  in  computer  memory  and  then  provided  each  partition  10-20 
millisecond  (msec)  intervals  of  processing  time.  This  allowed  each  user  to  be  unaffected 
by  the  presence  of  other  users  on  the  system  and  to  perceive  that  he  was  using  a  stand¬ 
alone  microcomputer.  The  operating  system  also  provided  for  quick  system  startup,  user 
access  security,  use  of  command  words  and  files  for  repetitive  operations,  help  state¬ 
ments,  disk-to-disk  software  backups,  and  various  printer  output  options.  The  higher- 
level  language  used  by  the  system  was  an  extended  version  of  BASIC  that  included  name- 
length  variables,  memory  mapping,  and  labeled  subroutines.  The  operating  system 
software,  including  file  and  commands  necessary  to  operate  the  AM-1031  microprocessor, 
is  described  in  detail  in  the  manufacturer's  operations  and  technical  manuals. 

Data  Management  System 

Both  COONTZ  and  RADFORD  were  provided  with  a  data  management  system  (DMS) 
called  AMS,  which  was  commercially  developed  by  Applied  Micro  Systems,  Ltd.  AMS 
automatically  provided  for  the  creation,  data  entry,  updating,  and  report  generation  from 
user-defined  data  files  or  data  bases.  The  system  also  provided  detailed  documentation  of 
file  layouts  and  interrelationships  between  files.  AMS  was  totally  conversational,  which 
meant  that  users  could  respond  to  questions  asked  by  the  system  on  the  video  display 
terminal.  Each  data  file,  report,  or  updating  or  input  routine,  when  established,  was 
automatically  added  to  a  series  of  customized  menus  displayed  at  the  user's  request.  The 
AMS  file  management  system  consisted  of  the  following  three  operating  modules;  (1) 
master  file  maintenance  and  generation,  (2)  input  generator,  and  (3)  report  generator. 

A  significant  feature  of  AMS  was  its  capability  to  establish  predetermined  record 
pointer  files  for  various  sorts  required  for  either  retrieving  records  by  user-oriented  keys 
(e.g.,  individual's  last  name  vice  S5N)  or  for  reporting  data  by  desired  sequences  (e.g., 
duty  section,  life-raft  assignment,  projected  rotation  date,  etc.).  These  pointer  files  were 
automatically  updated  by  AMS  whenever  a  user  entered  new  records  or  a  data  element 
that  had  been  flagged  by  the  system  as  a  sort  field  or  part  of  a  multiple-field  sort 
sequence.  This  indexing  capability  is  common  with  larger  DMSs  and  is  called  indexed 
sequential  access  management  (ISAM). 

Another  capability  of  AMS  was  its  ability  to  allow  users  to  define  easily  their  own 
data  files,  to  input  data  into  single  or  multiple  data  files  using  a  single-screen-formated 
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input  function,  and  to  output  data,  either  from  one  or  more  data  files,  onto  hard-copy 
reports.  All  this  could  occur  without  the  aid  of  a  professional  programming  staff  simply 
by  using  the  interactve  features  of  AMS.  If  the  user  had  programming  experience,  AMS 
was  able  to  generate  its  own  BASIC  language  source  code  based  on  the  user's  interactive 
inputs.  These  inputs  could  be  modified  by  the  user  as  necessary  to  facilitate  ease-of-use, 
local  unique  terminology,  or  data  entry  error  correction. 

No  formal  documentation  was  provided  for  the  AMS  DMS  software.  All  use  of  the 
the  DMS  depended  upon  self-teaching,  trial-and-error  experimentation,  and  on-board 
training  by  those  who  had  gained  experience  with  the  system.  COONTZ  enjoyed  an 
advantage  over  RADFORD  in  knowledge  of  the  use  of  the  DMS  because  the  COONTZ 
commanding  officer  (CO)  was  instrumental  in  selecting  the  AMS  DMS  and  had  worked 
closely  with  the  AMS  vendor  to  learn  the  system. 


Word  Processing  System 


Both  COONTZ  and  RADFORD  used  a  commercial  word  processing  system  (WPS), 
called  ALPHA  WORD,  for  general  correspondence  preparation  and  printing.  ALPHA 
WORD  had  the  capability  of  creating,  updating,  printing,  and  deleting  (1)  lists  (e.g.,  for 
mailing  labels  and  simple  sorts),  (2)  documents  (e.g.,  letters  and  ship's  instructions),  and 
(3)  standard  paragraphs  (e.g.,  those  used  in  preparing  the  ship's  plan-of-the-day  (POD)). 
The  Qume  printer-typewriter,  when  used  by  ship's  office  personnel  in  conjunction  with 
ALPHA  WORD,  produced  letter  quality  documents  easily  and  efficiently. 


Evaluation  Procedure 


Pertinent  microcomputer  system  documents  were  reviewed  and  selected  personnel 
were  interviewed  during  February  and  March  1981.  The  documents  reviewed  included 
DMS  computer-generated  documentation,  DMS  and  WPS  applications  outputs,  and  com¬ 
puter  equipment  operations  and  maintenance  manuals  and  logs. 


Interviews  were  conducted  with  shipboard  personnel  having  direct  or  indirect  use  of 
the  microcomputer  applications. 


FINDINGS 


System  Applications 


Data  Management  Applications 


During  the  period  between  March  1980  and  March  1981,  COONTZ  defined  approxi¬ 
mately  50  data  base  files  and  ship-generated  data  input  functions  with  over  80  hard-copy 
output  reports.  These  data  files,  input  routines,  and  output  reports  collectively  made  up 
the  COONTZ  DMS,  which  is  graphically  outlined  in  Figure  1. 


RADFORD  did  not  use  the  system -provided  DMS  except  in  a  few  isolated  cases. 
RADFORD  did  not  possess  the  training,  documentation,  nor  DMS  expertise  to  define 
adequately  the  data  bases,  develop  and  modify  the  input  routines,  and  format  the  output 
reports  as  required  by  the  DMS.  COONTZ,  on  the  other  hand,  had  the  on-board  expertise 
for  such  an  endeavor.  The  COONTZ  CO  not  only  possessed  DMS  and  programming  skills 
but  also  was  responsible  for  soliciting  financial  support  and  authority  for  the  two  acquired 
microcomputers  placed  in  COONTZ  and  RADFORD.  The  resources  and  general  command 
involverr  »nt  to  desi  i,  develop,  implement,  maintain,  and  revise  a  DMS  of  the  scope 
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Figure  1.  COONTZ  data  management  system  subsystem  structure. 


eventually  produced  aboard  COONTZ  could  not  have  occurred  in  RADFORD  without  an 
extreme  effort  by  the  ship's  managers  and  crew  to  learn  and  apply  the  DMS  by  trial-and- 
error.  However,  the  system-provided  WPS  offered  an  alternative  means  of  using  the 
microcomputer  for  simple  data  management  in  RADFORD.  Since  the  word  processor  was 
easy  to  use,  was  well  documented,  and  had  a  simple  sort  capability,  RADFORD  w as  able 
to  exploit  the  WPS  almost  as  fully  as  did  COONTZ  using  the  more  sophisticated  DMS. 

The  applications  developed  by  COONTZ  are  listed  in  the  appendix  and  discussed  in 
the  following  paragraphs. 

1.  Data  files.  Use  of  many  data  files,  rather  than  a  few  large  ones,  allowed 
COONTZ  to  exploit  the  DMS's  ISAM  capability  (described  on  page  2)  with  key  fields  or 
predefined  indexed  sequences  of  fields  that  could  be  instantaneously  updated  during  data 
entry  input.  This  ISAM  feature  allowed  the  use  of  more  familiar  secondary  key(s)  (e.g., 
last  name),  rather  than  more  complicated  or  sensitive  primary  key(s)  (e.g.,  SSN). 
COONTZ  had  no  desire  to  use  an  SSN  to  retrieve  a  personnel  record  when  an  individual's 
last  name  was  common  knowledge.  If  several  individuals  had  the  same  last  name,  the  user 
needed  only  to  "page”  alphabetically  to  the  record  desired.  Small  data  files  also  provided 
COONTZ  with  better  file  security  by  distributing  data  access  to  responsible  users.  This 
minimized  possible  data  loss  due  to  an  equipment  malfunction  or  human  error. 

2.  Input  routines.  COONTZ  was  able  to  input  data  into  the  data  files  via  either 
system-  or  ship-generated  input  functions.  Whenever  a  new  data  file  was  defined,  the 
DMS  automatically  generated  a  screen-formatted  input  function  that  could  be  used  to 
enter,  update,  or  delete  all  data  elements  for  that  data  file.  Using  an  alternative  input 
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mechanism,  COONTZ  generated  its  own  input  functions  using  the  DMS  input  generator 
option.  This  option  allowed  COONTZ  to  develop  input  routines  that  could  enter,  update, 
and  delete  data  associated  with  a  subset  of  the  data  from  one  or  more  data  files.  Since 
the  DMS  generated  BASIC  source  code,  COONTZ  was  able  to  modify  the  coding  to 
incorporate  ease-of-use  prompts,  help  statements,  local  unique  terminology,  and  date 
conversion  algorithms  (e.g.,  Julian  date  format). 

3.  Output  reports.  The  output  reports  developed  by  COONTZ  output  data  from  one 
or  several  data  files,  list  from  3  to  23  data  elements,  and  produce  hard-copy  outputs  with 
up  to  220  columns.  Similarly,  COONTZ  was  able  to  modify  system-generated  source  code 
in  order  to  insert  user  selection  queries  (e.g.,  program  queries  user  as  to  which  work 
center  to  report  data  on),  perform  calculations,  and  format  the  hard-copy  output  for  more 
than  the  traditional  SO  or  132  columns. 

Word  Processing  Applications 

The  WPS  was  used  extensively  aboard  both  COONTZ  and  RADFORD  to  prepare  text 
documents,  such  as  memoranda,  letters,  ship's  instructions  and  notices,  ship's  bills, 
standard  operating  procedures,  lesson  plans,  and  naval  messages.  Larger  and  more  static 
documents,  such  as  ship's  instruction,  were  stored  off-line  on  spare  disk  packs  that  were 
placed  on-line  for  retrieval,  review,  and  updating.  These  updated  instructions  were  then 
easily  retyped  and  redistributed  using  the  system  printer  or  Qume  typewriter-printer  and 
the  ship's  copier  machine.  The  WPS  even  had  the  capability  to  select  which  pages  to 
retype  to  facilitate  making  small  changes  to  large  documents. 

With  a  multiterminal  WPS,  as  in  COONTZ  and  RADFORD,  word  processing  became 
an  "all  hands"  system  that  allowed  personnel  other  than  ship's  office  personnel  to  access 
and  to  perform  word  processing.  Officers,  chief  petty  officers,  and  many  petty  officers 
interacted  with  the  WPS  to  perform  many  daily  routine  and  ship-internal  correspondence 
tasks.  For  example,  even  the  traditional  pocket  notebook  or  "wheelbook"  was,  in  many 
instances,  replaced  by  a  WPS  file  (e.g.,  supply  part  stock  number  and  pricing  notes,  work 
center  rosters,  tickler  notes).  Also,  preformatted  naval  message  texts  (some  with 
embedded  help  remarks  in  the  fill-in-the-bianks  spaces)  could  be  easily  retrieved,  edited, 
and  added  by  using  the  WPS  cursor-controlled  commands. 

COONTZ  made  excellent  use  of  the  WPS  standard  paragraph  utility  for  preparing  the 
ship's  plan-of-the-day  (POD).  For  example,  pertinent  information  (e.g.,  that  on  seasonal 
dress  and  working  uniforms,  duty  section  watch  assignments,  ship's  daily  routine,  safety 
precautions  notes,  and  damage  control  questions)  was  pretyped  as  standard  paragraphs, 
perhaps  weeks  or  months  in  advance,  by  cognizant  personnel  and  then  retrieved  as  simple 
coded  commands  by  the  ship's  office  yeoman  to  "build"  and  print  the  next  day's  POD.  A 
sample  COONTZ  POD  that  was  produced  using  standard  paragraphs  and  typed  by  the  WPS 
Qume  typewriter-printer  is  shown  in  Figure  2. 

As  mentioned  above,  RADFORD  favored  the  WPS  over  the  DMS  for  performing 
selected  data  management  functions.  The  WPS  could  perform  these  functions  because  of 
its  limited  sort  (list)  capability  and  ease  by  which  changes  could  be  made  to  existing 
reports.  The  categorical  WPS  application  areas  used  by  RADFORD  are  listed  in  the 
appendix.  Note  that  several  of  the  applications  were  similar  to  COONTZ's  DMS 
applications.  Applications  used  in  RADFORD  that  were  not  attempted  in  COONTZ 
included  using  the  WPS  to  produce  personnel  qualification  standards  (PQS)  cards  for 
lookout,  sound-powered  telephone  talker,  and  helmsman;  inspection  check-off  lists; 
master -at-arms  law  enforcement  documents;  small  arms  inventory  and  control  lists;  and 
air  detachment  check-off  lists. 
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DUTY  OFFICERS 
CDO:  LTJG  COSTA 
OPS:  LT  SEXTON 
WEPS:  FTMl  EMERY 
ENG:  MM1  BARRS 
SUP:  SK2  WILSON 
X/N:  LTJG  MILLER 


OOD  WATCHBILL 
08-12:  RM1  THOMAS 
12-16:  LT  SEXTON 
16-20:  FTMl  EMERY 
20-24:  GMT1  KING 
00-04:  EMI  ALEMAN 
04-08:  ENS  HIGGENBOTHAM 


DUTY  SECTION  FIVE 
DUTY  MAA:  FTMl  BIBEAULT 
DUTY  YN:  SN  CHANDLER 
DUTY  RM:  RM3  JACKSON 
DUTY  SM:  QM2  GALLO 
DUTY  DR:  RM3  JACKSON 
SEC  LDR:  DSC  BARNETT 


SHIP'S  ROUTINE 


Schedule  is  in  accordance  with  the  Routine  of  the  Day  as  published  in  the  SORM  for 
Holiday  Routine  inport  with  the  following  exceptions: 

0800  -  MUSTER  DUTY  SECTION 
0900  -  OOD  PQS 

1630  -  DUTY  INPORT  FIRE  PARTY/Z-27-D 
HAPPY  BIRTHDAY:  NONE 


ALL  HANDS  ARE  RESPONSIBLE  FOR  THE  CONTENTS  OF  THE  POD 


ORDERS  OF  THE  DAY 

1.  STRIKER  SELECTION  BOARD.  Membership  of  the  Striker  Selection  Board  shall 
consist  of  an  enlisted  representative  from  each  department,  minority  representation,  and 
shall  include  the  master,  senior,  or  chief  petty  officer  of  die  command  as  chairman,  and 
the  command  Career  Counselor,  when  assigned.  The  senior  personnelman  assigned  shall 
be  a  member  (voting  or  non-voting)  and  shall  provide  qualification  information  to  the 
board. 

2.  SECURITY  NOTE.  Espionage.  There  are  no  current  indications  of  activity  by  hostile 
intelligence  services  in  the  Norfolk  area.  However,  all  COONTZ  personnel  should  be  alert 
to  the  fact  that  intelligence  agents  would  likely  concentrate  their  attention  on  personnel 
whose  conduct  (e.g.,  sexual  promiscuity,  need/greed  for  money,  drug  dealing,  etc.)  would 
make  them  vulnerable  to  blackmail.  COONTZ  personnel  should  avoid  involvement  in  such 
compromising  situations.  COONTZ  personnel  must  also  promptly  report  to  their  superiors 
suspicious  contacts  with  foreigners,  or  any  request  for  defense  information. 

DC  QUESTION.  Q.  What  size  plug  is  recommended  for  an  8"  hole? 

A.  10"  plug 

3M  QUESTION.  Q.  If  a  monthly  maintenance  requirement  was  accomplished  once 
during  a  quarter,  is  a  notation  required  on  the  back  of  the  quarterly  schedule? 

A.  Yes 


D.  S.  BUI 
CDR  USN 

EXECUTIVE  OFFICER 


System  Reliability  and  Maintainability 


During  the  12-month  period  between  March  1980  and  March  1981,  the  microcomputer 
systems  in  COONTZ  and  RADFORD  did  not  malfunction.  Consequently,  no  downtime 
statistics  were  available.  One  SOROC  terminal  in  COONTZ  had  a  bad  resistor,  which  was 
replaced  by  ship's  force  personnel.  A  spare  parts  kit  was  provided  to  both  ships  by  the 
equipment  iea$ing  vendor  but  was  never  needed  for  repairs.  Two  ship's  company  personnel 
from  each  ship  had  attended  a  2-week  maintenance  training  course.  However,  they  were 
not  needed  due  to  the  "no  failure"  reliability  of  the  equipment. 

The  microcomputer  systems  in  both  COONTZ  and  RADFORD  were  subjected  to  a  full 
range  of  shipboard  environmental  conditions,  including  heavy  seas,  gun  or  missile  firings, 
full  power  and  backing  vibrations,  high  temperatures  (85-95°),  and  medium  to  high 
humidity  (75-85%).  No  system  degradation  was  experienced.  The  LA-120  terminal- 
printer  in  COONTZ  experienced  overheating  problems  that  were  corrected  by  turning  the 
printer  off  when  not  in  use.  Aboard  RADFORD,  the  microcomputer  system  was  often 
turned  off  before  or  during  any  periods  of  heavy  seas  or  loss  of  air  conditioning  as  a 
precautionary  measure.  Aboard  COONTZ,  the  system  (except  for  the  LA-120  printer) 
operated  continuously.  There  was  no  system  damage  nor  data  loss  due  to  power  problems. 
System  interruptions  or  failures  were  never  experienced  due  to  transient  power  fluxua- 
tions. 

Planned  maintenance  for  the  microcomputer  systems  was  minimal  and  consisted, 
primarily,  of  cleaning  system  parts,  such  as  filters,  disk  read/write  recording  heads,  CRT 
key  contacts,  and  printers  for  paper  debris. 

System  Operation  and  Utilization 

System  Startup  and  Shutdown 

The  system  operator  was  able  to  start  the  microcomputer  by  energizing  the  power-on 
switches  to  the  CPU,  disk  drives,  and  peripherals  and  by  "booting"  the  system  by  pushing  a 
RESET  button  on  the  CPU.  Startup  operation  required  about  a  minute.  Shutdown 
procedures  followed  a  similar  sequence  in  reverse  order  but  required  that  (1)  all  on-line 
users  be  notified  in  advance  that  the  system  was  going  "down"  and  (2)  a  system  shutdown 
command  be  executed. 

User  Access.  Data  Input,  and  Report  Output 

Project  number  and  programmer  number  (PPN)  were  used  to  organize  disk  storage 
and  to  establish  protection  boundaries.  Each  user  was  required  to  "log"  into  his  assigned 
PPN  and  issue  the  password  associated  with  that  PPN.  Use  of  PPN  areas  or  accounts 
allowed  a  user  to  "read"  and  "write"  data  contained  in  his  area  or  other  areas  with  the 
same  project  number.  For  example,  aboard  COONTZ,  PPN  (100,100)  was  designated  as  a 
general  area  for  maintaining  and  reporting  data  related  to  maintenance  and  supply 
functions  and  w as  accessible  by  most  maintenance  and  supply  petty  officers.  Access  into 
the  DMS  or  WPS  required  that  the  user  enter  a  short  command  word  (i.e.,  "DB"  or  "AW" 
respectively).  Upon  entering  the  DMS  or  WPS,  the  user  either  interacted  with  a  list  of 
options  (menu)  or  entered  other  command  words  to  retrieve  the  desired  applications. 
Sensitive  applications,  such  as  pricing  of  new  requisitions,  required  the  user  to  enter  a 
second  password.  In  most  applications,  help  statements  and  user-oriented  prompts  were 
available  or  presented  to  the  users.  Output  reports,  when  executed  by  a  user,  were 
printed  at  the  LA-120,  removed  and  stacked  by  personnel  working  in  the  lower  CIC,  and 
later  picked  up  by  the  requesting  user. 


System  Backup 

To  preclude  catastrophic  loss  of  stored  data  and  programs,  the  data  from  the  on-line 
disk  packs  were  transferred  daily  to  off-line  disk  packs.  The  operating  system  was 
capable  of  copying  an  entire  disk  and  verifying  the  copy  by  comparing  it  with  the  parent 
disk.  Both  COONTZ  and  RADFORD  used  this  copy  feature  of  the  system  to  backup  the 
disk.  A  disk-to-disk  backup  of  the  data  and  programs  on  file  took  from  2  to  3  hours.  A 
shorter  backup  of  critical  data  files  was  backed  up  daily  in  COONTZ  and  took  about  an 
hour.  COONTZ  would  perform  the  full  system  backup  at  least  once  a  week?  and 
RADFORD,  once  a  month.  In  a J1  cases,  backup  operations  required  the  system  manager  to 
take  the  system  off-line  for  dedicated  use  until  the  bacKQp  was  completed.  The  reason 
for  this  was  because  the  only  two  disk  drives  available  on  the  system  were  both  required 
for  a  disk-to-disk  backup. 

System  Proximity  and  Availability 

User  proximity  to  one  of  the  six  video  display  terminals  and  consistent  system 
hardware/software  reliability  provided  both  COONTZ  and  RADFORD  with  quick  and 
direct  access  to  the  DMS/WPS  application  programs  and  data  files.  This  terminal 
proximity  and  system  availability  were  considered  excellent  when  only  the  six  terminals 
were  in  demand.  When  additional  terminals  were  required,  as  during  periods  of  peak 
system  load,  some  users  became  impatient  and  frustrated  while  waiting  for  their  turn  to 
get  "on-line." 

System  Utilization  and  Ease  of  Use 

Aboard  COONTZ,  an  average  of  four  users  were  on  the  system  from  0800  to  2000 
daily  entering  and  retrieving  data.  Based  on  user  interviews,  approximately  30  percent  of 
the  personnel  assigned  to  COONTZ  interacted  directly  on-line  with  the  microcomputer 
with  50  percent  of  the  crew  depending  on  the  system's  hard-copy  outputs.  Aboard 
RADFORD,  15  percent  of  the  crew  interacted  with  the  microcomputer  with  nearly  50 
percent  using  the  outputs.  Aboard  COONTZ,  more  than  80  DMS  administrative  and  data 
system  reports  were  outputted  and  distributed  (see  appendix).  RADFORD,  which 
depended  more  upon  the  WPS  than  the  DMS,  produced  almost  200  word  processing  output 
types  for  their  general  administration  and  clerical  purposes.  Both  ships  developed  great 
dependency  upon  the  microcomputer  system  capabilities  as  a  data  file  manager  and  word 
processor.  Removal  of  the  system  from  either  ship  was  deemed  (at  least  emotionally  if 
not  literally)  "catastrophic."  The  systems  were  used  by  all  pay  grades.  The  WPS  found 
good  usage  by  chiefs  and  officers  who  were  required  to  draft  messages,  instructions, 
notices,  watchbills,  and  general  internal  correspondence.  The  DMS  applications  in 
COONTZ  were  particularly  suited  to  meeting  a  large  variety  of  shipboard  local-unique 
functions  or  those  general  informal  reports  and  correspondence  that  must  be  generated  by 
the  ship's  various  work  units  on  a  periodic  basis.  Both  the  DMS  and  WPS  were  generally 
easy  to  use,  as  evidenced  by  the  number  of  non-A DP-trained  or  inexperienced  personnel 
on  both  ships  who  used  the  computers'  capabilities.  New  users  were  interacting  with  the 
system  after  only  a  few  hours  of  hands-on  indoctrination.  Ease-of-use  was  facilitated  by 
help  statements  and  prompts  and  by  selection  of  DMS/WPS  applications  that  had 
high/frequent  usage  in  a  manual  state  before  they  were  automated. 

System  Security  and  Privacy 

System  security,  as  mentioned  above,  generally  involved  limiting  the  data  flies  and 
functions  available  to  each  user  by  assigning  "user  areas"  (computer  accounts),  each  with 
its  own  PPN  and  password.  This  form  of  area  or  cell  security  was  sufficient  for  the  WPS 
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and  operating  system  functions  but  suffered  when  using  a  DMS,  as  in  COONTZ.  Since  a 
DMS  must  meet  the  needs  of  several  levels  of  management  and  cross  organizational  unit 
boundaries,  DMS  users  in  COONTZ  had  to  be  grouped  in  a  small  number  of  DMS  function- 
oriented  user  areas  (e.g.,  maintenance).  Consequently,  some  DMS  users  had  access  to  and, 
if  inclined,  could  have  tampered  with  the  data  files  of  other  DMS  users  in  the  same 
account.  This  mechanism  of  pooling  DMS  users  weakened  system  security  somewhat  but 
did  make  the  DMS  in  COONTZ  usable  and  more  responsive.  (There  were  no  reports  that 
data  were  ever  intentionally  or  accidently  corrupted  or  lost  by  a  DMS  user.) 

System  security  was  complemented  by  the  ship's  own  physical  security  systems. 
Video  display  terminals  were  always  located  in  manned  or  locked  spaces.  Armed  watch 
personnel,  who  guarded  the  ship  against  access  by  unauthorized  personnel  and  damage  by 
fire  or  flooding,  precluded  any  noncrew  member  from  gaining  access  to  the  micro¬ 
computer  hardware  and  software.  Also,  there  was  no  off-ship  telecommunication  capa¬ 
bility  by  which  an  individual  could  access  the  system  files  by  a  remote  telephone  data 
system. 

Akin  to  system  security  was  privacy  of  personnel  data,  such  as  pay  and  medical  data. 
System  privacy  was  maintained  by  use  of  PPN  user  accounts  and  passwords  (single  and 
double)  and  ship-tailored  input  routines.  The  latter  not  only  facilitated  ease  of  data  entry 
but  also  restricted  a  user  "view"  or  updating  accessibility  to  a  need-to-know  subset  of 
data  elements  from  the  DMS  personnel  data  files. 

System  Responsiveness 

System  responsiveness  of  the  microprocessor  and  its  applications  was  adequate  and 
did  not  disrupt  user  productivity.  Response  delays  for  system  log-ins,  operating  system 
commands  and  queries,  and  DMS/WPS  data  entry  were  negligible  (.3  to  4  seconds).  Wait 
time  for  most  DMS/WPS  and  operating  system  outputs  ranged  between  4  seconds  for  a 
simple  word  processing  text  to  3  minutes  for  a  single  file  data  management  report.  In 
some  instances,  however,  up  to  30  minutes  would  elapse,  as  in  the  case  of  a  large 
multifile,  multikey  DMS  report  (e.g.,  master  personnel  roster),  before  printing  would 
actually  commence  after  a  print  request  had  been  initiated  by  a  user.  These  delays, 
although  considered  long  by  users  of  minicomputers  or  large  mainframe  computers,  were 
not  perceived  to  be  detrimental  to  the  shipboard  users.  When  response  delays  were 
predictable  by  the  user  (e.g.,  when  he  was  aware  of  system  loading  fluctuations  or  knew 
the  report  being  processed  was  complex),  the  system  was  still  considered  "responsive”  to 
that  user  because  the  microcomputer  could  produce  an  output  faster  and  neater  than  if  he 
had  prepared  it  by  typewriter. 

System  Data  Storage  Capacity 

On-line  disk  data  storage  of  ten  million  bytes  (10MB)  was  adequate  for  initial  uses  of 
the  microcomputer  systems  aboard  COONTZ  and  RADFORD.  In  COONTZ,  however,  the 
DMS/WPS  data  storage  requirements  soon  outgrew  the  allotted  on-line  10MB.  Since  3MB 
of  on-line  data  was  stored  on  a  removable  disk  pack,  lower  priority  data  files,  such  as  WPS 
files  for  ship’s  notices  and  instructions,  had  to  be  stored  off-line  on  extra  3MB  disk  packs 
until  needed  by  a  system  user.  When  off-line  stored  data  were  requested,  the  system 
manager  had  to  secure  the  system  and  "mount”  the  extra  disk  for  the  requesting  user(s). 
This,  in  turn,  denied  other  system  users  access  to  data  files  on  the  original  disk  pack. 
Thus,  timesharing  of  disk  packs  became  a  system  management  routine  for  accessing  all 
the  DMS/WPS  data  in  COONTZ.  In  RADFORD,  on  the  other  hand,  sufficent  space 
remained  on  the  two  on-line  disks  to  accommodate  their  WPS  applications. 


System  Flexibility  and  Adaptability 

Since  the  microcomputer  system  D MS/WPS  software  itself  promoted  an  evolutionary 
growth  of  data  management  subsystems  and  word  processing  text  libraries,  system 
flexibility  and  system  adaptability  were  essentially  "built-in"  and  depended  solely  upon  the 
need  for  change  or  new  applications  by  the  users  and  upon  the  expertise  Of  the  onboard 
system  designer-developers.  Since  individual  WPS  users  were  primarily  their  own 
designers  and  developers,  they  had  both  the  autonomy  and  the  flexibility  to  shape  their 
respective  WPS  libraries  to  meet  their  particular  needs.  The  DMS  in  COONTZ,  however, 
depended  more  on  a  functional  group-oriented  design  and  development  effort.  The  CO  of 
COONTZ  took  the  role  of  the  initial  DMS  system  analyst  and  DMS  applications 
development  engineer.  The  users  of  a  new  application  provided  system  feedback  for 
improvement  or  ideas  for  new  DMS  applications. 

User  Acceptability 

User  acceptability  of  the  microcomputer  system  was  good.  General  user  awareness 
of  DMS/WPS  functionality,  coupled  with  demonstrated  knowledge  that  the  system  could 
perform  immediately  on  the  job,  contributed  directly  to  system  user  acceptability.  For 
some  users,  the  fact  that  they  were  allowed  to  request  and  receive  modifications  and/or 
new  applications  or  be  involved  directly  in  the  design  of  an  application  was  sufficient  to 
gain  their  complete  acceptance  of  automating  a  previously  manual  operation.  Similarly, 
when  a  newly  reported  DMS  user  was  allowed  to  invoke  his  own  desired  changes  into  an 
existing  application  (e.g.,  add  a  new  data  element  to  a  report),  the  system  became  more 
"acceptable”  to  that  user. 

Also,  it  was  noted  that  computer  games  were  an  effective  means  of  familiarizing  a 
new  user  with  the  microcomputer  and  dispelling  any  fears  he  may  have  about  computers. 

System  Transportability 

The  microcomputer  system  hardware,  as  previously  mentioned,  could  be  disassembled 
and  carried  by  one  or  two  personnel  to  any  other  ship  location  or  into  another  ship  without 
difficulty.  Since  no  special  "militarization"  of  system  components  was  necessary  prior  to 
installation,  system  reinstallation  could  be  accomplished  in  less  than  5  working  days  with 
ship's  company  personnel  assisting  by  securing  the  hardware  and  laying  cables  for  the 
peripheral  devices. 

System  software  would  be  directly  transferable  to  a  new  system  hardware  location. 
Translation  of  the  system  software  for  use  on  another  manufacturer's  computer  hardware 
appears  impractical  due  to  the  many  nonstandard  and  vender -unique  features  of  the  Alpha 
Micro  and  AMS  software.  However,  for  a  computer  containing  a  comparable  DMS  and 
WPS,  a  near  duplicate  set  of  DMS/WPS  applications  could  be  created  in  a  reasonable  time 
(1  to  3  months)  with  vendor  and  user  support. 

System  Personnel  and  Logistic  Support 

The  microcomputer  systems  in  COONTZ  and  RADFORD  were  operated  and  managed 
by  a  data  systems  technician  (DSC  in  COONTZ}  DS2  in  RADFORD).  Since  COONTZ  had 
created  a  larger  integrated  DMS  involving  a  larger  percentage  of  the  crew  than  had 
RADFORD,  the  DSC  in  COONTZ  spent  about  43  percent  of  his  assigned  duties  as  the  DMS 
system  manager.  Hie  system  manager-operator  carried  out  the  following  tasks: 


1.  Performed  troubleshooting  for  both  hardware  and  software. 


2.  Performed  system  analysis  and  D MS-level  application  programming. 


3.  Operated  all  microcomputer  equipment,  created  and  debugged  new  DMS  applica¬ 
tions,  and  detected  and  corrected  program  errors. 

4.  Performed  disk-to-disk  backup  of  system  data  files  and  programs.  Managed 
storage  and  on-line  time  of  the  system  disk  packs. 

5.  Trained  new  system  users. 

6.  Maintained  on-hand  A  DP  supplies,  such  as  computer  paper,  printer  ribbons,  and 
report  binders. 

Both  COONTZ  and  RADFORD  provided  data-entry  terminal  operators  from  the 
department,  division,  or  work  center  using  and  maintaining  a  data  file  or  word  processing 
application.  These  operators,  from  all  pay  grades,  could  type  and  usually  had  a  direct 
responsibility  for  the  data  or  words  maintained  for  them  by  the  microcomputer.  It 
required  1  to  2  hours  of  system  indoctrination  to  teach  a  new  user  to  properly  log-on  to 
the  microcomputer  and  to  start  entering  data  or  words  for  his  particular  application.  The 
SOROC  IQ-120  video  display  terminals  were  used  by  all  users  as  input  devices  to  the 
computer  with  output  on  either  the  DECwriter  III  LA-120  or  the  Qume  printer-typewriter. 

The  microcomputer  system  was  supportable  and  self-sufficent  in  the  shipboard 
environment.  As  previously  mentioned,  ship's  force  was  tasked  to  operate  and  maintain 
the  microcomputer  system.  The  ship's  Type  Commander,  however,  was  always  available 
for  additional  support,  if  required. 

System  Benefits 

Aboard  both  COONTZ  and  RADFORD,  the  DMS/WPS  applications  were  designed  and 
developed  by  ship's  company  personnel  using  a  microcomputer-based  DMS  and  VPS  to 
meet  each  ship's  unique  recordkeeping  and  reporting  requirements  for  selected  shipboard 
administrative  functions.  The  benefits  derived  from  these  DMS/WPS  applications  are 
discussed  in  the  following  subparagraphs. 

Shipboard  Operations 

The  most  significant  overall  benefit  that  resulted  from  the  ship-initiated  micro¬ 
computer  applications  in  COONTZ  and  RADFORD  was  in  general  shipboard  operations. 
Specifically,  this  resulted  from  the  capability  of  the  DMS/WPS  to  (1)  facilitate  the 
accessibility  of  information  for  better  planning  and  decision  making,  (2)  increase  the 
quality  of  the  ship’s  administrative  functions  by  reducing  errors  and  improving  typing 
clarity,  and  (3)  reduce  the  manual  administrative  workload,  providing  shipboard  managers 
greater  opportunities  to  manage.  These  beneficial  attributes  are  illustrated  below  for  the 
three  DMS  application  subsystems  in  COONTZ  shown  in  Figure  1. 

1.  Administration 


a.  General. 


(1)  Assisted  in  ship's  office  operations  with  tickler  information  on  prospec¬ 
tive  gains  and  losses,  good  conduct  awards  due,  deliquent  general  damage  control  (GDC) 
PQS  qualifications,  birthdays,  time-in-rate  (for  next  advancement),  and  general  counts  of 
on-board  rates  and  ratings. 


(2)  Facilitated  the  accurate  accounting  of  assigned  personnel  with  com¬ 
puter-generated  personnel  rosters  and  muster  reports. 

(3)  Assisted  die  administration  of  personnel  work  assignments  and  workload 
planning  by  promulgating  duty  status  information  on  individuals  scheduled  for  temporary 
additional  duty  (TAD),  schools,  leave,  or  transfer. 

(4)  Enhanced  inport  watch  wake-up  and  locator  efficiency  by  listing  on¬ 
board  personnel  and  their  compartment  bunk  assignments. 

(5)  Facilitated  the  promulgation  of  the  ship's  command  policies  and  direc¬ 
tives  by  systematizing  the  revision  and  reprinting  of  ship's  notices  and  instructions. 

(6)  Supported  the  Navy's  enlisted  retention  programs  by  providing  the 
career  counselor  with  computerized  aids  to  track  career  interviews  and  potential 
reenlistments. 

(7)  Enhanced  the  ship's  public  affairs  program  by  producing  mailing  address 
labels  for  multiple  types  of  general  public  and  dependent  mailings. 

(8)  Assisted  in  die  awareness  of  the  operation  department's  combat  readi¬ 
ness  by  keeping  and  promulgating  availability  of  departmental  equipment. 

(9)  Assisted  in  the  proper  dissemination  of  naval  messages  by  maintaining 
an  accurate  communications  routing  guide  for  radio  central  personnel. 

(10)  Facilitated  internal  communications  by  maintaining  and  listing  the  ship's 
service  telephone  directory. 

(11)  Facilitated  the  retrieval  of  weapon's  operating  and  maintenance  infor¬ 
mation  by  maintaining  accurate  listings  of  weapon  publication  inventories,  locations,  and 
changes  entered. 

(12)  Supported  combat  readiness  by  facilitating  missile  inventory  manage¬ 
ment  and  monitoring  of  missile  maintenance  due  dates. 

b.  Job/duty  /watch  assignment. 

(1)  Contributed  to  watchstation  and  combat  readiness  by  facilitating  the 
management  of  General  Quarters  and  Condition  III  biliet-job  watchstation  assignment 
data. 


(2)  Supported  shipboard  physical  security  by  facilitating  the  preparation  of 
in-port  duty  section  watchbill  assignments  and  distribution  of  qualified  personnel  in  each 
duty  section. 


(3)  Contributed  to  personnel  safety  at  sea  by  producing  accurate  liferaft 
lists  and  muster  sheets. 

(4)  Enhanced  inport  emergency  readiness  by  producing  accurate  personnel 
recall  information. 

c.  Planning/training.  Supported  training  readiness  by  providing  exercise, 
inspection,  and  general  event  history  records,  weekly  training  planners,  and  schedules. 


d.  School. 


(1)  Facilitated  the  deficit  reduction  of  required  on-board  school  graduates 
by  maintaining  and  reporting  data  on  required  schools  versus  on-board  graduates  for  each 
school. 


(2)  Facilitated  the  reduction  of  school  quota  no-shows  by  disseminating 
information  on  filled  and  vacant  quotas. 

(3)  Facilitated  the  TAD  processing  of  prospective  school  candidates  by 
promulgating  timely  notice  of  school  quotas,  convening  dates,  and  designated  attendees. 

e.  Physical  security. 

(1)  Contributed  to  shipboard  nuclear  weapons  security  by  producing  accu¬ 
rate  and  up-to-date  personnel  reliability  program  (PRP)  personnel  assignment  and 
controlled/limited  access  lists. 

(2)  Enhanced  quarterdeck  access  by  promulgating  accurate  visitor  clearance 
lists.  (These  computerized  lists  greatly  reduced  the  delay  time  previously  required  to 
page  through  hundreds  of  loose-leaf  visit  request  forms  and  messages). 

f.  Medical. 

(1)  Systematized  and  facilitated  general  preventive  medical  scheduling  by 
maintaining  and  listing  status  on  annual  physical  examinations,  dental  examinations, 
audiograms,  and  immunization  shots. 

(2)  Supported  medical  treatment  readiness  by  providing  quick  and  accurate 
inventory  accounting  of  authorized  medical  allowance  list  (AMAL)  supplies  and  on-board 
personnel  sources  of  various  types  of  blood. 

g.  Enlisted  dining  facility.  Facilitated  enlisted  dining  preparation  efficiency 
by  providing  menu  planning  and  food  preparation  aids. 

2.  Maintenance 

a.  Zone  inspection. 

(1)  Enhanced  awareness  of  the  ship's  material  condition  by  the  quick 
dissemination  of  updated  material  zone  inspection  results. 

(2)  Facilitated  correction  of  zone  inspection  discrepancies  by  promulgating 
inspection  results  to  responsible  work  centers  in  work  center  compartment  order. 

b.  Equipment  discrepancy/corrective  maintenance.  Enhanced  awareness  of 
combat  readiness  by  facilitating  the  logging"  and  corrective  maintenance  monitoring  of 
work  center  equipment  discrepancies  and  by  supporting  the  Navy's  casualty  reporting 
system. 


c.  Supply.  Enhanced  supply  support  responsiveness  by  facilitating  the  proces¬ 
sing,  budgetary  control,  and  monitoring  of  outstanding  supply  requisitions. 

3.  Personnel  Qualifications— PQS.  Assisted  personnel  qualifications  management  by 
(a)  establishing  standards  for  PQS  training  "tracks'5  for  each  work  center,  (b)  centralizing 


command  monitoring  of  personnel  qualifications,  and  (c)  automating  work  center  PQS 
progress  charting. 

Clerical  Efficiency  and  Productivity 

Complementing  the  contributions  of  the  DMS/WPS  to  shipboard  operations  was  the 
system's  contribution  to  increased  clerical  efficiency  and  productivity.  There  was  no 
typing  backlog  evident  in  COONTZ.  Even  long-term,  nice-to-have,  typing  chores,  such  as 
redoing  the  Ship's  Organization  and  Regulations  Manual,  were  done  in  COONTZ-  In  fact, 
yeomen  (YN)  personnel  were  freed  to  assist  with  departmental  typing  and  administration 
that,  heretofore,  had  been  left  to  inexperienced  seamen  and  firemen  drawn  from  the 
departmental  ranks.  A  target  turnaround  time  for  any  routine  typing  chore  in  COONTZ 
was  24  hours.  While  the  author  was  on  board  COONTZ,  an  emergency  request  to  type  a 
new  and  large  damage-control-oriented  ship's  instruction  was  made  upon  the  ship's  office. 
The  typing  task  was  done  by  close  of  business  the  same  day  using  the  system's  word 
processing  capability.  Also,  since  the  WPS  was  available  for  non-YN  personnel,  would-be 
typing  chores  were  often  undertaken  by  these  individuals.  This  not  only  allowed  them  to 
get  their  typing  done  quicker  and  to  their  own  specifications  without  interacting  with  the 
YN  typing  pool  but  also  eased  the  workload  on  the  ship's  office. 

Similarly,  other  ship's  managers  (e.g.»  duty  section  watch  coordinators,  storekeepers, 
vork  center  supervisors,  and  training  managers)  experienced  the  same  "catching-up" 
phenomenon  using  the  DMS  and  felt  that  their  management  skills  were  better  exercised. 
This  may  have  occurred  because  (1)  their  data  were  "in  order"  (up-to-date,  accurate,  and 
neatly  formatted)  and  (2)  they  had  more  time  to  reflect  on  those  data  for  planning  and 
decision  purposes  rather  than  spending  their  time  collecting  and  presenting  it  to  others. 
Their  productivity  as  ship's  managers  was,  consequently,  enhanced.  Another  example 
supporting  this  productivity  attribute  of  the  DMS  was  seen  when  the  department  heads 
inputted  planning  data  into  the  planning  board  for  training  (PBFT)  planner,  which  was 
subsequently  used  as  a  planning  aid  for  the  forthcoming  week's  schedule  of  events.  The 
DMS  seemed  to  "impose"  upon  the  department  heads  the  need  to  (1)  submit  their  training 
requirements  and  event  dates-times  and  (2)  resolve  problems/differences  with  other 
departments'  plans  before  the  PBFT  meeting.  This  premeeting  activity  saved  time  and 
avoided  much  interdepartmental  argument  in  the  presence  of  the  executive  officer  (XO), 
who  presided  as  the  PBFT  chairman. 

Management  Control  and  User  Interdependency 

The  more  sophisticated  DMS  application  subsystems  in  COONTZ  depended  upon 
multiple  data  input  routines.  Reports  from  these  applications  were,  in  turn,  widely 
distributed  (e.g.,  intermediate  maintenance  activity  (IMA)  work  status  reports)  and/or 
were  used  by  a  few  key  shipboard  managers  for  planning  and  decision  purposes  (PBFT 
Planner).  This  input-output  interrelationship  of  a  previously  manual  information  operation 
resulted,  when  automated,  into  more  visible  and  comprehensible  functional  interdepen¬ 
dency  between  data  entry  operators  and  DMS  report  users.  This  user  interdependency 
added  a  synergistic  quality  to  die  multi-user  DMS  applications  and  promoted  a  total  team 
effort  in  COONTZ  that  may  not  have  been  present  in  the  pre-DMS  situation. 

Not  only  did  some  DMS  applications  in  COONTZ  tend  to  unite  system  users  into  a 
more  functional  team  by  the  imposed  information  structure  of  the  DMS  application  itself, 
but  also  the  outputs  themselves  effected  a  self-correcting  quality  control  phenomena. 
For  example,  personnel  with  missing  liferaft  assignment  data  always  appeared  at  the  top 
of  the  Liferaft  Listing  report.  Since  the  DMS  could  quickly  correct  and  reprint  a 
corrected  report,  it  became  a  simple  act,  if  not  a  compulsive  one,  for  the  first  lieutenant 


(as  in  this  case)  to  do  so.  Another  phenomenon  that  promoted  DMS  quality  control  was 
when  ship's  managers  displayed  a  direct  interest  in  the  DMS  outputs.  Aboard  COONTZ, 
the  CO  received,  at  the  beginning  of  each  week,  a  bounded  subset  of  DMS  reports  for  his 
perusal.  This  act  of  interest  and  the  very  presence  of  these  reports  in  the  CCfs  cabin 
encouraged  accuracy  and  completeness  of  their  contents. 

Corporate  Memory 

In  many  instances,  aboard  both  COONTZ  and  RADFORD,  the  data  management  and 
word  processing  efforts  of  relieved  or  transferred  individuals  were  easily  passed  on  to 
relieving  personnel,  hence  preserving  and  perpetuating  the  corporate  memory  of  the  data 
that  was  generated  and  successfully  used  by  others  in  the  past.  The  computer-based 
endeavors  of  one  personnelman  first  class  (PN1)  aboard  COONTZ  were  inherited,  learned, 
and  improved  upon  by  a  relieving  PN1  to  keep  and  enhance  the  corporate  memory  and 
capabilities  of  the  ship's  administrative  office.  Similarly,  the  microcomputer  system 
facilitated  the  ease  and  quickness  of  the  turnover  of  department  head  responsibilities  by  a 
newly  reported  weapons  officer.  RADFORD,  when  relieved  of  deployment  duties  by 
another  ship,  was  likewise  able  to  turn  over  quickly  computer-generated  standard 
operating  procedures  (SOT)  documents  and  messages  to  the  relieving  U.S.  Navy  ship  for  its 
immediate  use,  thus  preserving  the  corporate  memory  of  inter -Navy  procedures,  lessons 
learned,  and  communication  formats. 

Computer  Literacy 

Many  crew  members  aboard  both  COONTZ  and  RADFORD  were  exposed  for  the  first 
time  to  an  interactive,  state-of-the-art  computer  system  and  obtained  hands-on  experi¬ 
ence  on  the  operation  and  cababilities  of  a  computer-based  DMS  (COONTZ)  and  WPS 
(COONTZ  and  RADFORD).  This  involvement  afforded  the  crews  of  both  ships  a  degree  of 
computer  literacy  heretofore  not  experienced  by  shipboard  personnel.  Each  crew  was  able 
to  gain  first-hand  insight  and  appreciation  of  the  advantanges  and  disadvantages  of  a 
shipboard  ADP  system  that  will  aid  them  in  future  use  of  other  systems,  both  ashore  and 
afloat. 

Job  Satisfaction 


Several  individuals  aboard  both  COONTZ  and  RADFORD  indicated  that  their  jobs  had 
been  enriched  because  of  the  microcomputer.  The  two  system  managers  and  their 
assigned  (or  volunteer)  helpers  enjoyed  their  work,  although  it  usually  entailed  extra  hours 
to  perform  both  their  regularly  assigned  duties  and  work  associated  with  the  microcom¬ 
puter.  To  them,  the  microcomputer  system  was  an  avocation  that  elevated  their  status 
aboard  ship  as  the  "system  experts."  Others  who  used  the  microcomputer  to  generate 
reports  or  documents  delighted  in  the  positive  feedback  they  received  from  supervisee, 
subordinates,  and  peers  in  the  promptness,  accuracy,  and  neatness  of  their  computer¬ 
generated  outputs  (e.g.,  watchbills,  internal  memorandums,  rosters,  etc.).  Generally,  the 
microcomputer  was  perceived  as  contributing  to  shipboard  administration  and  increased 
job  satisfaction  for  those  who  benefited  from  its  use. 

System  Costs 

Fiscal  Costs 


The  microcomputer  system  hardware,  software,  maintenance,  and  support  personnel 
cost  approximately  $50,000  for  each  ship.  A  detailed  cost  breakdown  is  presented  in 
Table  1.  ADP  consumables  (paper  and  ribbon)  cost  about  $1 34  aboard  COONTZ  and  $70 
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Table  1 


COONTZ  DMS  Cost  Data 


Item 

Cost 

Hardware: 

Central  Processing  Unit  (AM-1301) 

$30,650 

w/256  KB  MOS  Memory 

10  MB  CDC  Disk  Drive 

12  I/O  Ports 

Hash  Filter  and  Rack 

SOROC  120  CRT  Terminals  (6) 

5,600 

QUME  Printer 

3,000 

DECwriter  in  LA-120  Printer 

2,500 

Cabling/connectors 

500 

Installation 

NC 

Subtotal 

42,250 

Software: 

AMS  Data  Management  System 

4,000 

ALPHA  WORD  Word  Processing 

1,000 

AMOS  and  AlphaBASIC 

NC 

Subtotal 

% 

5,000 

Maintenance: 

Spare  parts  kits 

2,800 

Training 

1,000 

Subtotal 

3,800 

Total 

$51,050 

Note.  There  were  no  personnel  costs. 


for  RADFORD  per  month.  No  monthly  costs  were  incurred  for  spare  parts  because  the 
systems  never  failed.  No  costs  were  recorded  for  personnel  since  no  new  billets  were 
assigned  to  either  ship  to  support  the  microcomputer  system.  Commander  Naval  Surface 
Force,  U.S.  Atlantic  Fleet  (COMNAVSURFL  A  NT)  leased  the  two  microcomputer  systems 
for  about  $10,000  per  year.  Adding  annual  operating  costs  of  $1,200  for  ADP  consumables 
and  $1,000  contingency  for  repairs  (not  needed  in  1981),  a  total  annual  cost  of  $12,200  was 
required  to  lease  and  operate  the  microcomputer  in  each  ship. 
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System  Manning  and  Personnel  Training 


The  cost  to  man  and  operate  the  microcomputer  system  and  the  ship-initiated 
applications  in  COONTZ  and  RADFORD  was  more  one  of  reallocated  man-hours  than  any 
fiscal  outlay  of  money.  A  conservative  estimate  of  8000  man-hours  per  year  was 
expended  in  COONTZ  for  shipboard  personnel  to  attend  to  the  needs  of  the  micro¬ 
computer  hardware*  software,  DMS,  and  WPS  (7000  man-hours  for  data  input-output 
assuming  an  average  of  four  CRT  terminals  on-line  per  8-hour  day;  1000  man-hours  for 
system  management  and  operating  tasks  and  user  training  assuming  an  average  of  45% 
time  spent  in  .system  support  by  the  assigned  system  manager). 

Except  for  the  man-hours  expended  by  the  system  manager,  it  is  estimated  that  the 
man-hours  reallocated  by  the  DMS/WPS  users  to  use  the  computer  to  help  them  perform 
their  job  was  equal  to  or  less  than  those  that  would  have  been  required  if  they  had 
continued  to  carry  out  those  same  assigned  duties  manually.  Thus,  the  residual  cost  to 
man  the  microcomputer  system  and  train  user  personnel  was  the  man-hours  spent  by  the 
assigned  system  manager.  Aboard  COONTZ,  the  system  manager  (DSC)  had  excellent 
subordinate  assistance  to  help  him  to  supervise  and  manage  his  work  center  personnel  and 
ship's  work.  This  gave  the  DSC  the  time  to  perform  the  tasks  associated  with  being  a 
microcomputer  system  manager.  On  RADFORD,  on  the  other  hand,  the  system  manager 
(DS2)  was  heavily  committed  to  perform  work  center  maintanence  tasks  at  the  expense  of 
his  system  manager  functions.  This  could  account,  in  part,  for  the  fewer  system  backups 
and  limited  DMS  applications  in  RADFORD. 

Application  Development  and  Documentation 

No  off-ship  Navy  or  contractural  system  analysis  and  programming  support  was 
provided  to  either  COONTZ  and  RADFORD  for  DMS/WPS  design,  development,  imple¬ 
mentation,  and  documentation.  This  effort  was  accomplished  solely  by  interested  and 
contributing  ship's  company  personnel  and  required  hundreds  of  man-hours.  The  principal 
contributor  to  the  design,  development,  and  implementation  of  the  DMS  in  COONTZ  was 
the  ship's  CO,  who  because  of  his  unique  skills  and  dedication,  was  able  to  simultaneously 
command  his  ship  and  construct  a  viable  DMS  system.  This  effort  was  atypical. 
Fortunately,  such  a  feat  needed  only  to  be  accomplished  once  for  COONTZ  and,  perhaps, 
not  at  all  for  other  ships  with  an  identical  microcomputer  and  similar  DMS  requirements. 


LESSONS  LEARNED 

Since  the  introduction  of  integrated  circuits  in  the  mid-1960s,  the  size  and  cost  of 
computers  has  diminished.  A  like,  but  opposite,  increase  in  the  procurement  of  computers 
for  commerical,  military,  and  personal  use  followed.  In  1975,  the  Navy  established  the 
Chief  of  Naval  Operations-sponsored  Shipboard  Nontactical  AW5  Program  (SNAP)  as  an 
effort  to  provide  computers  to  all  combatant  ships  for  a  variety  of  nontactical  ADP 
administrative  functions.  This  program  is  ongoing  and  installation  of  such  computers  into 
fleet  units  will  commence  in  late  1982.  Similarly,  inexpensive  and  versatile  microcom¬ 
puter  systems,  outside  the  purview  of  SNAP,  are  beginning  to  appear  in  ships  to  satisfy 
various  ship-internal  administrative  requirements  that  were  either  deferred  or  not 
envisioned  by  SNAP. 

The  microcomputer  systems  installed  in  COONTZ  and  RADFORD  represent  one  of 
the  first  and  largest  ship-initiated  endeavors  not  under  the  auspices  of  SNAP  to  utilize 


microprocessor  technology  afloat  for  nontactical  A  DP  functions.  Lessons  learned  from 
this  undertaking  are  summarized  below: 

1.  A  microcomputer  system  with  a  data  management  and  word  processing  capa¬ 
bility  can  have  a  major  impact  on  reducing  shipboard  administrative  burden  and,  in  turn, 
can  contribute  to  day-to-day  ship  operating  efficiency. 

2.  A  microcomputer-based  DMS  and  WPS  can  efficiently  and  effectively  allow 
ship's  company  personnel  to  generate  and  use  shipboard  local-unique  computer  applica¬ 
tions  without  the  aid  of  professional  programmers. 

3.  Typing  productivity  aboard  ship  can  be  increased  dramatically  by  a  multi- 
terminal,  multi-user  distributed  word  processing  cabability.  Such  a  capability  can 
facilitate  the  drafting,  storage,  and  editing  of  naval  messages  and  can  preclude  shipboard 
ADP  requirements  to  program  preformatted  messages  for  interactive  generation. 

4.  A  commercially  acquired  microcompouter  system  using  rotating  disk  storage 
ADPE  can  operate  reliably  without  special  ruggedization  in  the  at-sea  shipboard  environ¬ 
ment. 


5.  A  microcomputer  system  can  be  installed,  operated,  and  managed  by  ship's  force 
personnel.  An  individual,  trained  and  available  (3096-50%  of  assigned  duties),  should  be 
appointed  to  operate  and  manage  a  shipboard  microcomputer  system. 

6.  A  microcomputer  system  can  be  affordable  for  shipboard  use  on  an  annual  lease 
basis  ($10,000  per  year). 

7.  Ten  megabytes  of  on-line  mass  disk  storage  was  insufficient  to  support  the  local- 
unique  ADP  requirements  aboard  ship. 

8.  One  medium-speed  printer  and  one  slow-speed  letter-quality  printer  were 
sufficient  to  print  local-unique  ADP  hard-copy  outputs  aboard  ship. 

9.  Printers  with  compressed-print  capability  for  220-column  report  generation  can 
be  useful  for  displaying  multiple  data  element  files. 

10.  Six  video  display  terminals  were  insufficient  to  support  data  entry  during  peak 
user  periods  aboard  ship. 

11.  Disk-to-disk  backup  of  disk  media  stored  data  can  be  faster  and  as  reliable  as 
disk-to-tape  backups. 

12.  Microcomputer  hardware  and  software  documentation,  together  with  software 
embedded  application  menus  and  help  statements,  are  necessary  to  minimize  the  impact 
of  initial  system  implementation  and  user  indoctrination. 

13.  Microcomputer  user  acceptance  can  be  facilitated  by  promoting  user  computer 
involvement  with  a  user-relevent  application  and  by  using  computer  games. 

14.  Minor  microcomputer  system  response  delays  do  not  discourage  system  usage  if 
the  user  understands  the  nature  and  cause  of  the  delays. 

15.  Use  of  screen- formatted  input  routines  can  simplify  and  reduce  data  entry  time. 
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16.  Command  word  (vice  menu)  entry  can  facilitate  application  program  access  for 
experienced  users. 

17.  Logical  data  file  keys  (personnel  last  name,  equipment  nickname,  compartment 
name,  etc.)  are  a  more  desirable  means  to  retrieve  data  records  than  traditional 
alphanumeric  keys  (social  security  number,  job  sequence  number,  federal  stock  number, 
etc.). 

18.  WPSs  with  a  limited  sort  of  listing  capability  can  provide  a  simple  shipboard  data 
management  function. 

19.  Microcomputer  system  data  security  using  project-programmer  number  and 
password  can  be  adequate  for  single-user  word  processing  applications  but  may  not  be 
sufficient  for  multiple-user  data  management  applications. 

20.  A  microcomputer  system  can  promote  synergistic  team  support  for  some 
multiple-user  dependent  data  management  applications,  perpetuate  shipboard  corporate 
memory,  and  contribute  to  user  job  satisfaction. 

CONCLUSIONS 

The  use  of  a  microcomputer  system  with  a  data  management  and  word  processing 
capability  for  automating  selected  ship-internal  administrative  functions  appeared  to  have 
increased  clerical  productivity  and  operating  efficiency  in  both  COONTZ  and  RADFORD. 
The  introduction  of  a  comparable  capability  in  other  ships,  either  through  SNAP  or  by 
other  ship-initiated  means,  would  likely  produce  similar  benefits. 

RECOMMENDATIONS 

1.  Encourage  and  fund  micro-  or  minicomputer  ship-initiated  endeavors  in  order  to 
improve  shipboard  administrative  efficiency  and  combat  readiness  and  to  provide  useful 
feedback  to  related  shipboard  nontactical  A  DP  research  and  development  programs. 

2.  Incorporate  user -designed  and  command-managed  DMS  software  packages  into 
the  software  configuration  for  future  shipboard  nontactical  A  DP  or  WPS  implementation 
programs  to  support  local-unique  computer-based  applications. 

3.  Design  shipboard  WPSs  to  support  multiple  WPS  terminals  for  use  by  any  user 
required  to  draft  or  produce  typed  and  formatted  documents. 


COONTZ  DATA  MANAGEMENT  SYSTEM  APPLICATIONS 


Data  Files: 

Authorized  medical  allowance  list 
(AMAL)  inventory  file 
AMAL  issues  file 
AMAL  transaction  file 
Budget  allocations  file 
Career  counselor  data  file 
CIC  pass-down-the-line  file 
Clearance  list  file 
Communications  routing  guide  file 
Compartment  master  listing 
Condition  III  job-by-billet  file 
Crew  members  file 
Crew  recall  file 
Current  PQS  program  file 
Department  document  NR  control  file 
Duty  section  job  file 

3- section  duty  file 

4- section  duty  file 

5- section  duty  file 
Enlisted  dining  facility 

(EDF)  cycle  menu  file 
Exercise  communications  file 
General  quarters  (GQ)  job  by  billet  file 
Job  sequence  numbers  control  file 
Leave  requests  file 
Liferaft  assignment  file 
Mailing  list  file 
Medical  tickler  file 

Input  Routines  (ship-generated): 

Annual  physical  exam  date 
Audiogram  date  maintenance 
Blood  type  maintenance 
Career  prospects 

Casualty  correction  (CASCOR)  maintenance 

Casualty  report  (CASREPT)  maintenance 

Clearance  maintenance 

Cycle  menu  maintenance 

Date  of  rate  maintenance 

DC  PQS  status  maintenance 

Dental  data  maintenance 

Duty  status  maintenance 

EDF  maintenance 

EDF  menu  input 

IMA  estimated  time  to  repair  (ETR)  changes 
IMA  work  package  maintenance 
Leave  date  input 
Leave  status 

Liferaft  assignment  maintenance 
Mailing  list  maintenance 
Mailing  list  purge 
Medical  data  imput 


Missile  inventory  file 
Notices/instructions  revision  (5215)  file 
Navy  tactical  data  system  (NTDS)  circuit 
cards  file 

Operation's  equipment  status  file 
Pending  1250  requisition  file 
Personnel  reliability  program  file 
Phone  directory  file 
PQS  history  file 
PQS  standards  file 
PQS  track  file 
Recipe  cards  file 
Requisition  status  history  file 
Schedule  of  events  file 
School  quota  request  file 
School  requirements  file 
Schools  attended  file 
Standard  menus  file 
Supply  status  codes  file 
Supply  status  file 
1250  requisitions  master  file 
Tab  schedule  file 
Tread  status  file 
publications  inventory  file 
Work  center  equipment  deficiency  list 
(EDL)  file 

Zone  inspections  controls  file 
Zone  inspections  file 


New  man  entry 

New  requisition  document  input 
New  1250  requisition 
Personnel  reliability  program  (PRP) 
data  maintenance 
Qualifications  maintenance 

3- section  duty  maintenance 

4- section  duty  maintenance 

5- section  duty  maintenance 
Rack  number 

Rate  maintenance 

Recall  telephone  number 

School  quota  entry 

School  quota  maintenance 

Schools  attended 

Schools  requirement  input 

Situation  report  (SITREP)  maintenance 

Storekeeper  1250  maintenance 

Supply  status 

Tab  schedule  update 

Tread  schedule  update 

X-ray  date  maintenance 

Zone  inspection  results 

40Mart  input 
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AMAL  inventory  report 
AMAL  resupply  requirements 
Billet  number  list 
Birthday  list 

Career  counselor  data  report 
Career  counselor  interview  report 
Career  sea  pay  verification 
CASREPT  summary 
Communication  routing  guide 
Delinquent  DC  PQS  status 
Dental  class  statistics 
Department  budget  report 
Duty  section  assignments 
Duty  section  watchbill 
Eight  o'clock  reports 
Food  preparation  worksheets 
Good  conduct  tickler 
IMA  work  status 

IMA  work  status  by  job  sequence  number 

IMA  work  status  by  priority 

IMA  work  status  by  work  center 

Leave  date  listing 

Leave  personnel  by  date 

Liferaft  assignments 

Liferaft  muster  lists 

Mailing  list  verification 

Mandatory  turn-in  listing 

Master  personnel  roster 

Medical  data  report 

Medical  tickler  report 

Missile  inventory  report 

Missile  maintenance  due 

Muster  report 

Notice/instruction  revision  status 
NTDS  logic  cards 

Operation's  department  equipment  status 
Overdue  issue  listing 
Personnel  statistics  computations 
Personnel  statistics  report 
Planning  board  for  training  planner 
Prospective  gains  list 


PRP  access  lists 
PRP  ALPHA  listing 
PRP  FZ  lists 
PRP  personnel  listing 
PRP  safe  access  lists 
PQS  in  progress  report 
Rack  list  by  work  center 
Recall  bill 

Required  school  listing 
Requisition  poor  status  report 
Retention  interview  management  report 
Schedule  of  events 

School  dates  by  catolog  of  training  courses 
(CANTRAC)  number 
School  quotas 

School  requirement  planner 

Schools  attended  by  work  center 

Schools  attended  listing 

Security  clearance  lists 

Ship's  budget  report 

Storekeeper  1250  activity  report 

Supply  requisition  status 

1250  requisition  review 

Telephone  listing 

Time-in-rate-check 

Tread  status  projection 

Underway  exercises  schedule 

Universal  calender 

Unprocessed  1250  report 

Wardroom  meal  signup  list 

Weapon's  department  publications  inventory 

Weekly  EDF  menu 

Work  center  budget  report 

Work  center  consumption  report 

Work  center  equipment  discrepancy  listing 

Work  center  leave  listing 

Work  center  muster  lists 

Work  center  personnel  listing 

Work  center  requisition  status 

Work  center  zone  discrepancy  listing 

Zone  inspection  compartment  listing 

Zone  inspection  discrepancy  listing 
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RADFORD  WORD  PROCESSING  SYSTEM  APPLICATIONS 


Data  Files: 

Air  detachment  check-lists,  reports,  and 
messages 

Berthing  assignments* 

Budget  reports* 

CASREPT  requisition  status* 

Divisional  DCPO  assignments 
Duty  section  assignments  watches* 

Eight  o'clock  reports* 

External  correspondence 

Federal  stock  number  (FSN)  directories 

Inspection  check-off  sheets 

Internal  correspondence 

Lesson  plans 

Liferaft  assignments* 

Master-at-arms  administration 
Mess  cooking  administration 
Naval  message  drafting 
Notices/instructions 


Performance  evaluation  remarks 
Personnel/material  inspection  results 
Personnel  reliability  program 
administration* 

Personnel  roster  and  muster  reports* 
Plan-of-the-day  notes 
PQS  standards  cards 
Publications  inventories* 
Qualifications  tests-answers 
Report  and  action  tickler  files 
School  lists  and  convening  dates* 
School-of-the-ship  study  guides 
Ship's  general  and  emergency  bills 
Small  arms  inventory  control 
Standard  operating  procedures 
Training  schedules* 

Universal  calendars* 

Visitor  clearance  lists* 
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